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ON-DEMAND TRANSPORTATION SYSTEM 

Inventor 
Ryan M. Hileman 

Field of the Invention 
10 This invention relates generally to transportation systems and, more specifically, to an 

on-demand transportation system and method used to coordinate passenger and package 
transportation and calculate the charges for such services. 
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Background of the Invention 
Public transportation has long been available to route passengers to various 
15 destinations. There are significant advantages to public transportation over private 
transportation. Public transportation involving one or a few passengers, such as via taxi or 
shuttle, allows convenient pick up from and delivery to varied locations. Use of such public 
transportation eliminates the need to purchase, maintain and operate personal vehicles, 
thereby simplifying and reducing travel expenses for many individuals. Mass public 
% 20 transportation operates on a larger scale. Mass public transportation, such as via larger 
shuttles or buses, typically incorporates vehicles that allow transport of large numbers of 
passengers to their various destinations. Mass public transportation is made possible by 
fixing pick up and delivery locations and by scheduling travel based on standard routes of 
travel. 

25 One of the significant challenges to public transportation services involves calculating 

a passenger's fare. If the fare is calculated by distance traveled, it may not account for the 
time spent reaching the passenger pick up location, or the extra time spent carrying the 
passenger due to traffic conditions or other factors. A taximeter calculates the fare based on a 
combination of distance traveled and time stopped (or below a certain speed). Such a system 
30 does not account for time spent traveling slowly versus traveling along an uncrowded 
freeway. Moreover, such systems do not allow passengers to know in advance the amount of 
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the fare, creating discomfort for passengers who prefer to Imow the amount of the fare in 
advance. 

Mass public transportation and some taxi systems use a zone system to calculate set 
fares in advance of travel. Passengers pay according to the zone or zones in which they 
5 travel, as well as the time of day or week during which they travel. Zone systems do not 
typically account for traveling time, the time spent reaching the passenger pick up location, 
or the extra time spent carrying the passenger due to traffic conditions or other factors. 

Thus, there is a need for a system and method for evaluating transportation needs and 
calculating transportation charges that overcomes the noted disadvantages and provides an 
1 0 efficient and effective transportation system. 

Summary of the Invention 
The present invention provides an on-demand transportation system and method for 

scheduling passenger and package transportation. The system includes a user system for use 
J{ by a user to schedule passenger or package transportation, the user system having a 
#15 communications device capable of wired or wireless communication; a vehicle having a 

vehicle user for providing passenger or package transportation, the vehicle including a 
|J1 wireless communications device for transmitting and receiving wireless information, a user 
%1 interface for allowing the vehicle user to perform various interactive functions, and a 
s' processing system having a processor, a memory, and a database for controlling vehicle 

G 20 system components; a server maintaining information on logistical and geographic features 
jfi of the area for which transportation of passengers or packages is offered, information on the 
fU location, capacity, and availability of the vehicle to transport passengers or packages, and 
rf information on current, historical and anticipated traffic conditions along possible routes of 

■spas 

travel for which transportation of passengers or packages is offered; and a data channel 
25 providing wired or wireless communication among the user system, vehicle, and server. 

The method includes receiving transportation request information from the user 
system for passenger or package transportation via the data channel, determining optimal 
routes of travel for passenger or package transportation, calculating charges associated with 
optimal routes for passenger or package transportation, and notifying the user system of 
30 transportation options via the data channel. The transportation request information from the 
user system for passenger or package transportation may include origination, destination, 
travel time, and the number of passengers or type of packages to be transported. 

The step of determining optimal routes of travel for passenger or package 
transportation may include determining possible routes of travel based on the transportation 
35 request information, determining vehicles capable of providing the requested passenger or 

-2- 



HILE-1-1001AP 



package transportation along possible routes of travel, determining vehicle transportation 
information for vehicles capable of providing the requested passenger or package 
transportation along possible routes of travel, vehicle transportation information including 
vehicle location, capacity and availability information, and determining predicted traffic 
conditions along possible routes of travel based on existing and historical traffic conditions. 
These same factors may be considered in calculating charges associated with the passenger 
or package transportation. 

If the user selects one of the transportation options, the method includes ordering 
transportation according to the selected transportation option, scheduling transportation for 
the passenger or package according to the selected transportation option, and updating the 
server with information on the selected transportation option, 

The step of calculating charges associated with optimal routes for passenger or 
package transportation may include requesting account authorization for payment of the 
requested transportation if account information exists on the server associated with the 
passenger or package. If no account information exists on the server associated with the 
passenger or package, the server establishes an account associated with the passenger or 
package. Once a recognizable account is established, the server requests account 
authorization for the requested transportation. If account authorization for the requested 
transportation is obtained, the server charges the account associated with the passenger or 
package for the requested transportation. If at any point account authorization for the 
requested transportation is not obtained, the server notifies the user system of alternative 
payment options. 

As will be readily appreciated from the foregoing summary, the invention provides a 
system and method for evaluating transportation needs and calculating transportation charges 
that accounts for traveling time, traffic conditions, and other factors affecting the efficiency 
of the transportation process. 

Brief Description of the Drawings 

The preferred and alternative embodiments of the present invention are described in 
detail below with reference to the following drawings. 

FIGURE 1 is a diagram illustrating an exemplary system for performing functions of 
the present invention; 

FIGURE 2 is a flow chart illustrating an overview operation of the present invention; 

FIGURE 3 is a flow chart illustrating operation of the scheduling and charge 
determination aspects of the present invention; 
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FIGURE 4 is a flow chart illustrating operation of the account authorization aspect of 

the present invention; 

FIGURE 5 is a flow chart illustrating operation of an order delivery aspect of the 

present invention; 

5 FIGURE 6 is a flow chart illustrating operation of a service request aspect of the 

present invention; 

FIGURE 7 is a flow chart illustrating operation of package delivery aspect of the 

present invention; and 

FIGURE 8 is a flow chart illustrating operation of a passenger delivery aspect of the 

10 present invention. 

Detailed Description of the Preferred Embodiment 
The present invention provides a system and method for evaluating and scheduling 
transportation needs and calculating associated transportation charges. FIGURE 1 shows one 
embodiment of a transportation system 10 of the present invention. The transportation system 

15 includes a server system 20 in communication with a user system 30 and a vehicle 40 via a 
wired or wireless data channel 60. 

More specifically, FIGURE 1 illustrates the particular components of the embodiment 
of transportation system 10. Server system 20 includes a server 22 for housing user system 
information, as well as processing and responding to requests for information from user 

20 system 30 and obtaining and using information from information sources 24, which may be 
integral with or independent from server system 20. The server maintains information on 
streets, rails, airports, water ports, and other logistical and geographic features for the area for 
which transportation is offered. The server also maintains information on the location, 
capacity, and availability of vehicle 40, including such information as the number of current 

25 and predicted passengers or payloads, past routes of vehicle travel, current and future route 
assignments, vehicle attributes, and capacity based on current and predicted passengers or 
payloads. The server also maintains information on current., historical and anticipated traffic 
conditions along possible routes of travel supported by vehicle 40, as well as information on 
road condition and capacity. Current traffic condition information may include traffic data 

30 from Department of Transportation and other flow pattern and volume cameras and sensors; 
traffic data received real-time from vehicle 40 or other vehicles, whether part of or 
independent from transportation system 10; accident reports obtained from a number of 
sources, including law enforcement; and traffic data from other public and private sources. 
Historical and anticipated traffic condition information may include traffic condition data 

35 related to the day of the week, month and season; proximity in time to holidays or scheduled 
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events such as concerts, sports, and road construction work; and information related to users' 
prior experiences involving the same or analogous transportation. Server 20 may also include 
the identity and credit authorization information on user 32, as well as technical information 
on the vehicle, such as make, model and license. The server system may also maintain 
5 historical and current location information for the vehicle. 

In the preferred embodiment, server 22 includes a processor, a memory, and a 
database (not shown). Server 22 may be in communication with information sources 24 via 
direct access (e.g., hard-wired or point-to-point connection) as well as over Internet 26. 
Server system 20 further includes a means for sending and receiving information to and from 
10 vehicle 40, discussed below. In an alternative embodiment, server system 20 may include a 
human operator that receives and enters information into the server, and otherwise manages 
some or all of the server system operations. 

User system 30 includes user 32, which may be an automated system but in the 
preferred embodiment is a human operator. The user system further includes a 
1 5 communications device, such as a telephone 34 or a computing device 36 (e.g., PDA), or like 
device with wired or wireless communication capabilities, for transmitting and receiving 
information from user 32 to server 22 or other recipient. The communications device 
includes a communications interface, which may be integral with or a separate but connected 
part of the communications device. In an alternative embodiment, the user system further 
20 includes a global positioning system (GPS) 38 or other means (e.g., caller identification) for 
determining precise user system location. 

Vehicle 40 is preferably one or several vehicles in a fleet, such as a taxi, bus, or 
package delivery fleet, but may be any type or size of vehicle capable of meeting the 
transportation requirements of the present system, and may further include, for example, rail 
25 transit systems, delivery trucks, air travel systems, etc. In a preferred embodiment, vehicle 40 
includes a wireless communications device 42, such as a cellular modem, for transmitting 
and receiving wireless information; a user interface 44, such as a keyboard or microphone, 
for allowing the vehicle user to perform various interactive functions; a display 46; 
speakers 48; a processing system 50, preferably having a processor, a memory, and a 
30 database (not shown), for monitoring and controlling vehicle system components, and a 
GPS 52 for determining precise vehicle location. In an alternative embodiment, GPS 52 may 
be replaced by a different system, such as a manual system, where the precise vehicle 
location is determined and communicated in another fashion, such as by a human operator. 

Data channel 60 facilitates communication of instructions and information among 
35 server 20, user system 30, and vehicle 40. In a preferred embodiment, the data channel may 
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include a satellite system 62 in combination with a satellite dish 64, along with or in the place 
of one or more access points 66, the latter as part of a cellular or other wireless transmission 
network. The data channel may also include means for direct access (e.g., hard-wired or 
point-to-point connection), such as over a telephone line or via the Internet. 
5 In operation, information and instructions are transmitted from user system 30 via 

communications device 34 or 36, or vehicle 40 via communication device 42, to either the 
satellite "system or access point, which in turn communicate the instructions to server 
system 20, in the former case via satellite dish 64. In an alternative embodiment, information 
and instructions may be transmitted directly from user system 30 to the server system, for 
10 example via hard-wired or point-to-point communication. Conversely, information and 
instructions may be communicated from the server to the vehicle along a reverse direction of 
the same route. 

An overview operation of the present invention is understood with reference to 
D FIGURE 2. At block 200, user 32, via user system 30, provides server system 20 and, 
f 15 ultimately, server 22, with transportation request information, and requests transportation 
B options from the server system. The user may seek transportation for either a passenger, such 
W as user 32, or for a package or other item to be transported for delivery to a specified 
S destination. At block 202, the server evaluates the transportation request information 
J provided by the user and determines transportation options, including available routes of 
U 20 travel (times, paths, etc.) and the charges associated with the various available routes of 
S travel. In the preferred embodiment, at block 204, the server saves the transportation options 
W in the server memory or database. Transportation request information, as well as determined 
P{ transportation options, may be saved at a single or several points during the described 
M operation. At block 206, the server notifies the user of transportation options, which includes 
25 travel parameters such as available routes of travel and associated charges. At block 208, if 
desired, the user selects one of the transportation options, and requests transportation 
according to the specified travel parameters. At block 210, the server books the requested 
transportation and notifies the transporting vehicle of the new transportation assignment. At 
block 212, the server or vehicle notifies the user of the imminent pickup of the passenger or 
30 package according to the transportation options. At block 214, the passenger or package is 
picked up and transported to the specified destination according to the transportation options. 

The specific operational aspects of the present invention are better understood with 
reference to the various alternative embodiments shown in FIGURES 3-8. FIGURE 3 is a 
flow chart illustrating operation of the scheduling and charge determination aspects of the 
35 present invention. While the system is equally applicable in the situation of a passenger or a 
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package delivery, it will be described principally with reference to the passenger situation 
only. At block 300, the server receives transportation request information from a user. The 
transportation request information preferably includes the passenger origination and 
destination (specific address or known transit or transfer center), the preferred travel times 
5 (month, week, day, hour or specific time of day), and the number of passengers or type and 
number of goods to be transported. The transportation request information may also include 
other information, such as specifics as to the mode of transportation desired, the preferred 
route taken, and an acceptable cost range. 

At block 302, the server determines the possible transportation routes based on the 
10 transportation request information. The possible transportation routes between the requested 
origination and destination are a function of the practical routes available between the two 
locations based on street, rail, airport, water port, and other logistical and geographic 
information maintained in the server database and the vehicles in the system capable of 

0 providing the requested transportation. Once the server has identified the possible 
f 15 transportation routes and the vehicles capable of providing transportation along the routes, at 
hi block 304, the server determines vehicle transportation information for the vehicles capable 
£n of providing the requested transportation. This is a function of current vehicle location, 
S capacity, and availability information, all of which is maintained in the server memory or 

1 database and updated as necessary to ensure real-time information is available to the server to 
%, 20 evaluate new transportation requests. Preferably, vehicle location and capacity information is 
5 updated automatically based upon sensory devices located in each vehicle, such as a GPS or 
K other location device to determine present vehicle location and sensors to determine open 
n seats or storage spaces. Vehicle availability information is preferably updated automatically 
h by the vehicle processor or the server, or both, as passengers or packages are added or 

25 removed. Vehicle availability information relates to the existing scheduled pickups and 
deliveries, including such information as the number of current and predicted passengers or 
payloads, past routes of vehicle travel, current and future route assignments and capacity 
based on current and predicted passengers or payloads. Vehicle transportation information 
(location, capacity, and availability) may also be updated by alternative means, for example 

30 by verbal communication from the vehicle user to the server system for subsequent entry into 

the server memory or database. 

At block 306, the server determines the predicted traffic conditions along the possible 
routes of travel. This is a function of current and historical traffic conditions along possible 
transportation routes supported by transportation vehicles. The server system obtains current 
35 traffic condition information (block 308) from information sources 24, which may include 
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traffic data from Department of Transportation flow pattern and volume cameras and sensors; 
traffic data received real-time from vehicle 40 or other vehicles, whether part of or 
independent from transportation system 10; accident repoits obtained from a number of 
sources, including law enforcement; and traffic data from other public and private sources. 

5 Historical traffic condition information (block 310), maintained in the server memory or 
database, may include traffic condition data related to the day of the week, month and 
season; proximity in time to holidays or scheduled events such as concerts, sports, and road 
construction work; and information related to the requesting passenger or sender's prior 
experiences involving the same or analogous transportation. 

10 At block 312, the server determines the optimal transportation routes based on the 

transportation request information, the vehicle transportation information, and the predicted 
traffic conditions. This may be a prioritized list of all possible routes and modes of travel, or 
a partial list showing only a predetermined number or type of routes and modes. At 
block 314, the server calculates the charges associated with the optimal transportation routes. 

15 The charge determined for each route is a function of the extent to which the resource, in this 
case the vehicle, is to be used by the passenger or sender. Stated differently, the charge is 
based on the lost opportunity cost of providing the requested transportation. The charge is 
calculated based first on how much time the passenger or package delivery will utilize the 
vehicle, and second how much time the vehicle will be "taken away" from other passengers 

20 using the service or package deliveries. For example, if a passenger is traveling to or from a 
place that is distant from all other current passengers, there may be a greater charge than a 
passenger traveling to or from a place in common to a maj ority of other passengers. In this 
example, the latter situation ties up less resources than the former, and thus there would be a 
lower associated charge. Various factors are evaluated in calculating the charges associated 

25 with optimal transportation routes. These factors may include the distance to be traveled 
between origination and destination; the proximity of the passenger or package pickup or 
delivery to the intended vehicle transportation route; the type of vehicle or mode of 
transportation involved; the condition of the transportation route (i.e., road condition); the 
weather conditions along the route; the predicted traffic conditions along the route; the 

30 current and anticipated schedule and transportation route of the vehicle; and priority of the 
existing and requesting passengers and packages. 

One of the advantages of the present invention is that it addresses the problem of 
efficiently reaching the last mile of passenger drop-off or delivery, getting the passenger or 
package to a location in close proximity to the destination for a predetermined or flat-fee 

35 charge. By using the outlined factors to determine identical and overlapping transportation 
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requirements, the present invention provides financially feasible point-to-point or near 
point-to-point transportation service. By using the outlined factors to assess proper resource 
value and calculate a highly accurate charge for transportation, the present invention provides 
a charge calculation that closely approximates the actual cost of providing the transportation 
5 resource, hi addition, the present invention addresses the granularity problem historically 
associated with public or pooled transportation, namely, the effect of incremental changes in 
travel schedule and traffic on changes to the amount of fare that a passenger must pay. Stated 
differently, existing public transportation models deal with the perception that there must be 
a substantial change between different trips to justify changes in fare required for each trip; 
10 i.e., one must travel a substantially greater distance to justify a larger fare, or the amount of 
traffic encountered must be substantial such as during rush hour to require a greater fare. The 
present invention evaluates many variables — allowing it to provide the advantages noted 
above, including a simple, fixed charge — without a surprising, after-the-fact, and often 
p substantial change in the charge. 

<) 15 At block 316, the server saves transportation request information and information on 

5 the determined optimal transportation routes and associated charges in the server memory or 
W database. Saving this information provides a backup record of the pending user transaction in 
m the event that communication with the user is terminated. Saving this information also allows 
43 for subsequent integration into historical database records for use to track consumer demand. 
JL 20 As noted above, transportation request information and information on the determined 
5 optimal transportation routes and associated charges may be saved at any time, or multiple 
1^ times, during the described system operation. 

% At block 318, the server sends optimal transportation routes and associated charge 

H information to the user. In an alternative embodiment, the server may send information in 

25 addition to only the optimal transportation routes, such as a prioritized list of all possible 
routes and modes of travel, or a partial list showing only a predetermined number or type of 
routes and modes. At decision block 320, a determination is made whether the user selected 
any of the proposed transportation routes. If the user declines to select a proposed 
transportation route, the logic of the system returns to block 300 to await a subsequent 
30 transportation request from the same or a different user. If the user selects a proposed 
transportation route, the logic proceeds to block 322. At block 322, the server obtains user 
identification information, books the requested transportation, and notifies the transporting 
vehicle of the new transportation assignment. User identification information may also be 
obtained at a different stage in the described operational logic, for example, at the time the 
35 user initially makes a transportation request (block 300). At block 324, the server updates 
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server memory or database with transportation information and the vehicle assignment, 
thereby updating the status of the vehicle for future transportation scheduling as well as 
enhancing the database with information to use in subsequent transportation option 
determinations, for example, providing specific user transfer parameters that may be 
referenced in future transportation requests to expedite the process. In an alternative 
embodiment, the vehicle updates the server with information on the completion of the 
transportation, including the specifics of the transportation time, the weather conditions, 
traffic conditions, etc. This information is added to the server database for use in subsequent 
transportation option determinations. The logic of the system returns to block 300 to await a 
subsequent transportation request from the same or a different user. Not shown or described 
in this example, but equally applicable to this embodiment, is the notification aspect of the 
invention described with reference to block 212 of FIGURE 2, and the accompanying 
specification. 

In an alternative embodiment, the server may book or reserve one or more optimal 
transportation routes (and save associated charge information) for the user at block 318, or 
prior to receiving the user request at block 320. In some instances the timeliness of reserving 
resources (vehicles) makes it important to act quickly, and the server, perhaps based on 
historical reservation fulfillment information for the particular user, may preemptively make 
the reservation. In addition, making the reservation at this stage may protect against 
accidental disconnect from the vehicle. If the user subsequently declines the travel option, the 
server immediately frees up the resource. 

Payment for transportation services may be accomplished in person or real-time at the 
passenger or package pickup or drop-off location. In an alternative embodiment, payment 
may occur electronically at any number of stages during the operational procedure described 
above, for example at the time that the server books the requested transportation. This 
electronic payment system can be used with any of the various embodiments of the present 
invention. With further reference to FIGURE 4, an electronic payment embodiment that may 
be incorporated into the operational logic of the present invention. At decision block 400, the 
server determines, based on user identification information, whether the user has account 
information on file in the server memory or database. If the user does not have account 
information on file, at block 402, the user is prompted to establish an account. At block 404, 
the user establishes an account recognizable by transportation system 10, and the logic 
continues to block 406. If, at decision block 400, the server detennines that the user has 
account information on file, the logic proceeds to block 406. 
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At block 406, the server prompts the user for authorization to charge the noted 
account for the cost of the requested transportation. This may be accomplished in a number 
or ways, such as verbally over telephone 34, or through electronic authorization via a 
computing device 36. If, at decision block 408, the user does not authorize the electronic 
5 transfer of the necessary funds, the logic proceeds to block 4 1 0, where the server notifies the 
user of alternative payment options, such as are described above. If, at decision block 408, 
the user authorizes transfer of the necessary funds, the logic proceeds to block 412, where the 
server charges the user's account for payment for the requested transportation. Preferably, 
mis is accomplished by charging a credit card number associated with the user. 
10 FIGURE 5 is a flow chart illustrating operation of an order delivery aspect of the 

present invention. In this embodiment, a passenger uses transportation system 10 to facilitate 
the timely and convenient delivery of goods ordered from a participating retailer. At 
block 500, a user intending to be a passenger in transportation system 10 remotely orders 
p goods from a participating retailer, for example over the telephone or via the Internet. The 
If 15 order preferably includes information such as the passenger's identification and anticipated 
[tj transportation schedule using transportation system 10. At block 502, the participating 
W retailer delivers the passenger's goods to a predetermined system repository or vehicle transit 
SI or transfer location. The goods are accompanied, at a minimum, by passenger identification 
M information and unique goods identification information. The goods may also be 
%, 20 accompanied by the passenger's anticipated transportation schedule. This information is 
5 forwarded to server system 20. In a preferred embodiment, information associated with the 
fl! goods, for example passenger identification information and goods identification 
information, are scanned into processing system 50 of vehicle 40 or at a system repository, 
H and the information is transmitted via data channel 60 to the server for integration with server 
25 memory and database records. 

At block 504, the server associates the passenger's goods with the passenger's 
transportation schedule. In other words, the server determines the most efficient manner and 
schedule to transport the passenger's goods to a vehicle to be ridden by the passenger in 
sufficient time that the passenger can link up with the goods enroute to the passenger's 
30 destination. This presupposes that the user is a passenger who has already made a request for 
travel on the system, or concurrently places a request for future travel. The association 
between the passenger's goods and the passenger's transportation schedule is preferably 
accomplished by accessing the receiving vehicle's intended route schedule and the 
passenger' s transportation schedule from the server memory or database, and determining the 
35 route that the goods must travel, including transfer to other vehicles and system repositories, 
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to reach the passenger's vehicle in time to connect with the passenger while the passenger is 
traveling on a vehicle to the passenger's destination. In a preferred embodiment, the 
passenger is notified that the package will be delivered to the vehicle. 

At block 506, the server initiates the transfer of the passenger's goods to the 
5 passenger's scheduled transportation vehicle. Preferably the passenger identification 
information and goods identification information, along with the passenger transportation 
schedule, is maintained in association with the goods throughout the process, and scanned in 
at each vehicle or repository for transfer and update of the information at the server. At 
block 508, the passenger connects with the goods on the scheduled transportation vehicle 
10 along the passenger's scheduled transportation route and, preferably, confirms receipt of the 
goods, which confirmation may be reported back to server system 20. 

FIGURE 6 is a flow chart illustrating operation of a service request aspect of the 
present invention. In this embodiment, an owner or user of a item to be serviced uses 
o transportation system 10 to facilitate the timely and convenient delivery and pickup of a 
w 15 service item from a service provider. At block 600, a user leaves the service item, for 
Jul example a clothing item to be dry-cleaned, with a vehicle at a vehicle transit or transfer 
HI location or at a system repository. In an alternative embodiment the service item receives 
£J curbside pickup. The user may have previously made arrangements with the service provider 
ji for which the service item is intended, or alternatively may use a service provider 
20 participating with transportation system 10, for which service provisioning has been 
23 prearranged. The service item is accompanied by user identification information and unique 
W service item identification information. The service item may also be accompanied by the 
% user's anticipated transportation schedule, should the user desire to coordinate delivery of the 
H serviced items to user transportation in transportation system 10. This information is 

25 forwarded to server system 20. In a preferred embodiment, information associated with the 
service item, for example user identification information and service item identification 
information, are scanned into processing system 50 of vehicle 40 or at a system repository, 
and the information is transmitted via data channel 60 to the server, for integration with 
server memory and database records. At block 602, the receiving vehicle delivers the service 
30 item to a vehicle at a vehicle transit or transfer location or a predetermined system repository. 

At block 604, the server initiates delivery of the user's service item to the specified 
service provider for service. After performing the requested service, at block 606, the service 
provider delivers the serviced item to a vehicle at a vehicle transit or transfer location or a 
predetermined system repository. The serviced item is accompanied by user identification 
35 information and unique service item identification information. The serviced item may also 
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be accompanied by the user's anticipated transportation schedule, should the user intend to 
be a passenger and to coordinate delivery with travel in transportation system 10. This 
information is forwarded to server system 20, again preferably by scanning pertinent 
information and electronic transfer. 
5 At block 608, the server associates the user's serviced item with the user's desired 

pickup location or, if the user is to be a passenger on trsinsportation system 10, with the 
user's transportation schedule, as outlined above. Once the necessary transfer route is 
determined, at block 610, the server initiates the delivery of the serviced item to the delivery 
location, or transfer of the user's serviced item to the user's scheduled transportation vehicle. 

10 Preferably the user identification information and goods identification information is 
maintained in association with the service item throughout the process, and scanned in at 
each vehicle or repository for transfer and update of the information at the server. At 
block 612, the user connects with the serviced item at the delivery location, on the scheduled 
transportation vehicle along the user's scheduled transportation route, or at another specified 

1 5 delivery location. In a preferred embodiment, the recipient confirms receipt of the item. 

FIGURE 7 is a flow chart illustrating operation of a package delivery aspect of the 
present invention. In this embodiment, a sender or receiver other than a passenger can use 
transportation system 10 to facilitate the timely and convenient pickup and delivery of 
packages anywhere within the system's service area. At block 700, a sender requests pickup 

20 of a package by providing pickup request information to sei-ver 22 via user system 30 across 
data channel 60. Pickup request information includes, foir example, package origination, 
destination, priority, and physical size and weight information. In an alternative embodiment, 
another agent may initiate the pickup request, even the recipient. At this or a later stage in the 
logic of the operation the sender provides the server with sender identification information. 

25 At block 702, the server evaluates the pickup request information and determines delivery 
options, including available routes and charges. This process is described in more detail with 
reference to blocks 302-314 of FIGURE 3, and the ZLCCompanying specification. At 
block 704, the server notifies the sender of the delivery options, including the pickup 
locations, delivery routes and charges. At block 706, the sender selects a delivery option, and 

30 requests pickup according to specified parameters. At block 708, using sender identification 
information, the server books the requested delivery and updates server memory or database 
with delivery information and the vehicle assignment, thereby updating the status of the 
vehicle for future transportation scheduling, as well as enhancing the database with 
information for use in subsequent transportation option determinations, for example, 

35 providing specific user transfer parameters that may be referenced in future transportation 
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requests to expedite the process. At block 710, the server notifies the transporting vehicle of 
the new transportation assignment. 

Once the vehicle assigned for pickup approaches the pickup location, at block 712, 
the server directly or through the vehicle notifies the sender of the vehicle's imminent arrival 
5 at the pickup location. This can be accomplished in a variety of ways, including by direct 
verbal contact, or by automated notification verbally or via remote electronic notification, for 
example via computing device 36. At block 714, the sender provides the pickup vehicle with 
the package, preferably including sender identification information, package identification 
information, destination information and recipient information. In a preferred embodiment, 
10 this information is scanned and transferred to the server. At block 716, the package is 
transported, as necessary, to the system repository or alternative delivery vehicle located 
along the scheduled delivery route. The package information is preferably scanned at each 
transfer location and the information is sent to the server to maintain and update records on 
q the status of the delivery. 

%0 15 As the delivery vehicle approaches the delivery destination, at block 718, the receiver 

fi is notified of the scheduled package delivery. As described above, this can be accomplished 
Lfl verbally or automatically by electronic means. The receiver is informed of the delivery 
;fj location and time so as to meet and obtain the package. In an alternative embodiment, 
Ig transportation system 10 allows the receiver input as to the delivery location. For example, 
20 the receiver, upon being notified of the scheduled package delivery, may alter the scheduled 
fSj delivery location or time, or in an alternative embodiment even the delivery recipient. At 
rll block 720, at the delivery location, the package is delivered to the receiver, preferably after 
!Jf appropriate receipt authorization is received and the package has been scanned at the 
*fk destination location. The server may subsequently be updated with this delivery information. 
25 FIGURE 8 is a flow chart illustrating operation of a passenger delivery aspect of the 

present invention. In this embodiment, a requestor seeks to schedule delivery of a package or 
other item or information to a passenger of transportation system 10. At block 800, a 
requester seeks to schedule the delivery of a package to a passenger. The requester provides 
the server with requester identification information, passenger identification information, 
30 and, if known, passenger schedule information. At block 802, the server evaluates the 
requester and passenger identification information by recalling and reviewing requester and 
passenger identification information and passenger transportation route information, if 
available. See generally the discussion above with reference to blocks 302-3 14 of FIGURE 3. 
At decision block 804, a determination is made whether, based on the requester's proposed 
35 delivery schedule and the passenger's scheduled travel route, the requested package delivery 
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is possible. If not, the logic proceeds to block 806, where the server notifies the requester of 
passenger unavailability. If the requested package delivery is possible, the logic proceeds to 
decision block 808, where a determination is made whether the requester is authorized by the 
passenger to make a package delivery. Previous passenger authorization may already be 
5 stored in the system for specific or ongoing deliveries from the requestor. If not, the logic 
proceeds to decision block 810, where the server, via known contact information or, if the 
passenger is currently traveling on the transportation system, via the passenger vehicle, 
attempts to contact the passenger. If the passenger cannot be contacted, the logic proceeds to 
block 806, where the server notifies the requester of passenger unavailability. If the server is 

10 able to make contact with the passenger, the logic proceeds to decision block 812, where a 
determination is made whether the passenger authorizes package delivery. If the passenger 
does not authorize package delivery, the logic proceeds to block 806, where the server 
notifies the requester of passenger unavailability. If the passenger authorizes package 
delivery, either at block 812 or directly based on previous authorization maintained by the 

15 server at decision block 808, the logic proceeds to block 814. 

At block 814, the server notifies the requester that package delivery has been 
authorized, and provides the requester with package drop-off options. La an alternative 
embodiment, at this or other stage in the described process, the server may request payment. 
See generally steps 400-412 of FIGURE 4, and accompanying specification. At block 816, 

20 the requester provides the package at the predetermined system repository or to a vehicle 
along a predetermined route, preferably including requestor identification information, 
package identification information, and passenger information. In a preferred embodiment, 
this information is scanned and transferred to the server. At block 818, the server initiates the 
transfer of the requester's package to the passenger's scheduled transportation vehicle. 

25 Preferably the passenger identification information and package identification information, 
along with the passenger transportation schedule, is maintained in association with the 
package throughout the process, and scanned in at each vehicle or repository for transfer and 
update of the information at the server. At block 820, the passenger connects with the 
package on the scheduled transportation vehicle along the passenger's scheduled 

30 transportation route. 

While the preferred embodiment of the invention has been illustrated and described, 
as noted above, many changes can be made without departing from the spirit and scope of the 
invention. As described above, the specific order in which the steps of the invention may be 
performed may vary substantially without sacrificing the fiinctionality of the invention. For 

35 example, the specific time at which transportation request or option information is saved to 
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the server, transportation reservations are made by the server, or users are charged or pay for 
system services, may vary. In addition, while notification of imminent passenger or package 
pickup is only described in certain situations, such notification may occur regardless of the 
particular embodiment. Likewise, the payment requests steps 400-412 described with 
reference to FIGURE 4, or equivalents thereof, may be used with or applied to any of the 
embodiments as a means of obtaining payment from users of the present system. In addition, 
while specific factors used to evaluate transportation options and calculate transportation 
charges are described, such factors are for exemplary purposes only; other factors may be 
included in making such evaluations and calculations. Also, it is anticipated that one or more 
of the alternative embodiments described be combined, in sum or total, to provide mixed 
transportation services, such as transporting both a package and a passenger, originating in 
different locations, to a common location. The disclosed and claimed transportation system is 
equally applicable to meet passenger, package, or passenger and package transportation 
needs. Accordingly, the scope of the invention is not limited by the disclosure of the 
preferred embodiment. Instead, the invention should be determined entirely by reference to 
the claims that follow. 
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